Could someone give me a hint on what security it buys to do a chroot before servicing a request from a network daemon? I guess it depends on what the attacker is able to find in the chrooted environment, if he can import programs, ... Good question. Chroot is a very strong (though not perfect) mechanism for restricting access to files. As such, it's very useful for things like ftp and gopher servers, and for some uses of http servers. It is not nearly as strong against programs that are executing in the chroot area, since other resources belonging to the machine are shared, notably its network identity. That's why it doesn't work as well for httpd -- most such servers want to execute perl scripts and other user-written goo, and chroot isn't a strong defense in this case (though it's certainly better than nothing). Also, if it is not too off-topic, what would be the best way to allow syslogs after a chroot, if the syslog daemon uses unix datagram sockets, that dont survive the chroot call? There are several approaches that have been used; all have their limitations. You could change the syslog subroutine to use the UDP port. You could use a UNIX stream socket. Or there's a hack that works on some systems, if you need only one chroot'ed syslogd... Make /dev/syslog a symlink to the real location of the socket, perhaps /usr/ftp/dev/syslog. Fire up syslogd with the (often undocumented) -p option, telling it the real location. Ordinary programs trying to send to /dev/syslog will follow the symlink. Ftpd will have its own /dev/syslog which is the real thing. And syslogd will get both of them. Note, of course, that this doesn't work if you need the same ability in ftpd and httpd, and they have separate chroot areas.